PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 3/USEnet 3.102

Text File | 1988-04-08 | 26.4 KB | 756 lines | [TEXT/ttxt]

 5-Dec-87 15:45:32-PST,27754;000000000001
Date: Sat 5 Dec 87 13:59:21-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V3 #102

Usenet Mac Digest     Saturday, December 5, 1987    Volume 3 : Issue 102

Today's Topics:
     What to do with 256Kbit SIMMs?
     Word Processing
     Re: What does 'ShutDown' do to Third Pa
     Basic for the Mac
     Re: More clipboard strangeness under MultiFinder
     MathView
     Re: Arabic Wordprocessing / Publishing Software wanted
     Re: One Quick and Dumb ?
     Re: Help with key1trans
     large monochrome monitors
     Installer 2.5--where there's a will (+1 meg), there's a way
     MPW C 2.0 Bug: PurgeSpace is foobar
     Source for Postscript
     Followup to corrupted Excel file problem.
     rect.top vs: rect.topLeft in C
     Re: 4Dimension ???
     Re: Help wanted:  a LSC question
     Re: One Quick and Dumb ?
     Re: Mac II power switch
     Turbo Pascal ideas...

----------------------------------------------------------------------

From: [e-mail] (Peter Steele)
Subject: What to do with 256Kbit SIMMs?
Date: 2 Dec 87 12:37:41 GMT
Organization: School of Computer Science, Acadia Univ., Nova Scotia

For sale: 2 256Kbit SIMMs in good working order (and one slightly
          used resistor :-})

Yes, I did it. I upgraded my SE to 2.5Megs. Now I am wondering what to
do with the old SIMMs. Does Apple have any interest in buying these
back? Does anybody know who might want to buy them? After all, they're
perfectly good SIMMs. They must be good for something?

--
Peter Steele Acadia Univ. Wolfville NS Canada B0P1X0 [phone]x121
UUCP:{uunet|watmath|utai|garfield}dalcs!aucs!Peter BITNET:Peter@Acadia


------------------------------

From: [e-mail] (Steven D. Leeke)
Subject: Word Processing
Date: 2 Dec 87 13:36:41 GMT
Organization: Stanford University

I've got the following minimum requirements for a WP:

    o Several thousand index entries
    o table of figures
    o table of tables
    o table of contents
    o foot/endnotes
    o bibliography
    o graphics blocks and in-line
    o style sheets
    o Full Mac editing/styles/etc.
    o Several hundred pages total (a single file or mult. linked files)

Since FullWrite is still VaporWare and WordPerfect is already 2 months
behind schedule I've been using Word 3.01.  It seemed to go well until I
hit Word's 1MB limit.  It seems pretty crazy that a program can read a
file in but not save it!  Word also has a hard time with a large index.

Is there a program I'm missing or do I have to wait for FullWrite,
InterLeaf, or FrameMaker?  What say ye?  Is there a program I'm missing?
 Is Microsoft going to update Word (Excel) to get rid of the 20b bug?

Thanks,

Steve Leeke

--
Steven D. Leeke, Center for Integrated Systems, Stanford University
    {ucbvax,decvax}!decwrl!glacier!leeke, [e-mail]

"I suppose they don't use money in the 23rd century?"


------------------------------

From: [e-mail]
Subject: Re: What does 'ShutDown' do to Third Pa
Date: 1 Dec 87 19:37:00 GMT


    According to IMV (beta draft), which I don't have in front of me, but I
have a pretty good recollection of the ShutDown Manager (after using it
to write my ShutDownSound INIT), the ShutDown command in the Finder
works as  follows:
    It calls the ShutDown Manager with trap _ShutDown with a selector of 2,
ShutDwnPower.  The ShutDown Manager then goes about its business of
shuttin down the Macintosh by first closing all open apps (if you are
running under MF), then closing all open Drivers (such as
DA's/Printer/Disk, etc.), then it goes through all mounted drives and
UnMounts them and then finally either turns itself off (if you are a Mac
][) or puts up that funky dialog.
    (If there is a ShutDownProc installed, like my SDSound, it will be
executed as part of this procedure as well).
    All this is described in IMV in the chapter on the ShutDown Manager, or
in my article in the September Issue of the Champaign-Urbana Macintosh
Users Group Newsletter.
--
+--------------------------------------------------------------------------+
+                                   |                                      +
+  Leonard Rosenthol                |  USnail:   205 E. Healey  #33        +
+  Halevai Software                 |            Champaign, Il  61820      +
+  GEnie: MACgician                 |                                      +
+  ARPA:  [e-mail]  |  Bitnet:   [e-mail]   +
+  {ihnp4|convex|pur-ee}!uiucuxc!clio!hannon                               +
+--------------------------------------------------------------------------+
+ Disclaimer #1: Since I own the company, I can say whatever I want, and   +
+                not be responsible for it!                                +
+                                                                          +
+ Disclaimer #2: Anything I say may be construed as being under the        +
+                jurisdiction of Disclaimer #1                             +
+--------------------------------------------------------------------------+


------------------------------

From: [e-mail]
Subject: Basic for the Mac
Date: 2 Dec 87 04:32:00 GMT


Does anybody out there know which brand of Basic for the Mac is the
best?  No language wars please!  This is for a young friend of mine who
will soon encounter Basic in school.

ZBasic looks interesting.  Is it friendly enough for a novice?


------------------------------

From: [e-mail] (Phil Goldman)
Subject: Re: More clipboard strangeness under MultiFinder
Date: 2 Dec 87 18:27:58 GMT
Organization: Apple Computer Inc., Cupertino, USA

Unfortunately, there really is no clean way to do this right now.
Calling _SysEdit as explained above will work, but a safer way is to
call _MenuKey(cmd-C), assuming of course that your app has an Edit menu
with cut, copy, etc. items.  This way you don't have to worry about any
possible side effects on DAs.

The reason all this is necessary is that it was determined that copying
large handles from application to application during layer switches
caused too great a performance hit.  Therefore, the clipboard is only
copied when MF senses that the user has changed it.  We realize that
this causes a problem for application-generated changes and we hope to
provide a standardized method for doing so in the future.

-Phil Goldman Apple Computer


------------------------------

From: [e-mail] (Robert Gardner)
Subject: MathView
Date: 2 Dec 87 17:49:25 GMT
Organization: Philips Research Labs, Sunnyvale, California

Does anyone have any experience with MathView for doing 3-D graphs,
etc.? Has it been released yet?

We're considering purchasing several copies but would like some feedback
first.
--
Thank you,
Robert Gardner


------------------------------

From: [e-mail] (Jordan Mattson)
Subject: Re: Arabic Wordprocessing / Publishing Software wanted
Date: 2 Dec 87 20:00:13 GMT
Organization: Apple Computer Inc., Cupertino, USA

A followup on Arabic Wordprocessing:

    Ready, Set, Go as distributed in Europe when combined with the Arabic
Interface System for the Apple Macintosh will allow you to use Arabic in
word processing and desk top publishing.  Do not buy the version of
Ready, Set Go distributed in the United States:  it does not work with
the Arabic Interface System.
    Ready, Set, Go is publised by Letraset.  Contact their international
division for more information.
    The Arabic Interface System is distrubited by Apple through APDA - the
Apple Programmer's and Developer's Association.

--
Jordan Mattson                UUCP:   ucbvax!mtxinu!apple!jordan
Apple Computer, Inc.            CSNET:     [e-mail]
Tools & Languages Product Management
20525 Mariani Avenue, MS 27S
Cupertino, CA 95014
408-973-4601
            "Joy is the serious business of heaven."
                    C.S. Lewis


------------------------------

From: [e-mail] (Oliver Steele)
Subject: Re: One Quick and Dumb ?
Date: 2 Dec 87 22:12:07 GMT
Organization: University of North Carolina, Chapel Hill

The Druid ([e-mail]) writes:
>  I have always wanted to write an application that does not use
>  the menu bar but instead DRAW USING THE FULL MAC SCREEN including
>  where the menu bar is. [...]

The easy way:
    GrafPort  myPort;
    OpenPort(&myPort);

The slightly more difficult way:
    WindowPtr myWindow;
    Rect      bounds;
    GrafPort  myPort;

    OpenPort(&myPort);
    bounds = myPort->portRect;
    ClosePort(&myPort);
    myWindow = NewWindow(0,&bounds,"\palmost always invisible :-)",
            false,0,-1,false,0);
    RectRgn(window.port.visRgn, &bounds);
    ShowWindow(window);

The advantage of the second way is that when the window goes away,
whatever was behind it is redrawn (you still need to do the menu bar and
desktop corners explicitly).  This way you can use it in a da or
multifinder-friendly application.

[e-mail] (Chuq Von Rospach) writes:
>I wouldn't recommend this, as it will cause the application to break under
>Multifinder.

You can still use the second way above.  I think it's pretty rude to do
this, so I check for the presence of MultiFinder to decide whether to
grab the whole screen or just throw up a window.  You should probably
either do this or only use the whole screen if the user requests.
--
------------------------------------------------------------------------------
Oliver Steele                  ...!{decvax,ihnp4}!mcnc!unc!steele
                            [e-mail]

    "Life isn't fair.  It's just fairer than death, that's all."
                            -- William Goldman
                              _The Princess Bride_


------------------------------

From: [e-mail] (Stew Rubenstein)
Subject: Re: Help with key1trans
Date: 3 Dec 87 01:27:19 GMT
Organization: Aiken Computation Lab Harvard, Cambridge, MA

key1trans is obsolete and unsupported.  The modern way to do this is
described in TechNote #160, Key Mapping.

--
Stew Rubenstein
Cambridge Scientific Computing, Inc.
UUCPnet:    seismo!harvard!rubenstein            CompuServe: 76525,421
Internet:   [e-mail]       MCIMail:    CSC


------------------------------

From: [e-mail] (Henry Kautz)
Subject: large monochrome monitors
Date: 2 Dec 87 19:19:25 GMT
Organization: AT&T Bell Laboratories, Murray Hill

Here is some information about large monochrome monitors for the Mac II
I've gathered, that should be of some interest....  This is not a
complete list --- I've not been able to get through to Megagraphics
(formerly Micrographics Images) to see if they have a Mac II video card
yet.  I got this info. from calling the companies --- note that it does
*not* always match what they're advertising!

 **************
 SUPERMAC
 415-964-8884

Produces *two different* mono. video cards, *both* called the Graphix.
One is 1280x960 (91 dpi), other is 1024x768 (73 dpi).  (Next year
sometime they'll sell a single card which can be configured -- at
installation time -- in either mode.)  Likewise sells *two different*
monochrome 19" monitors, one optimized for 91 dpi and the other for 73
dpi.  Be sure to get the one you want --- sometimes they ship mismatched
pairs, leading to lousy resolution!  The 91dpi board lets you see two
full pages on the screen at once, so is good for layout -- but small
fonts become hard to read.

Their monitor is produced by Moniterm, which also supplies Sigma Designs
and Moniterm's Viking.

They current have a *huge* backlog -- 4-8 weeks minimum. A number of
people I've talked to complain that the screens are not as bright or
contrasty as the Apple monochrome.

You can get tech support from Fabian Ramirez, 415-964-9660.

Incidently: if you want a *color* monitor from Supermac, be *sure* to
get the Trinitron one --- the non-trinitron one is pretty fuzzy.

Prices: $500 Grafix card, $1500 monitor

 *************
 Radius
 408-434-1010

Just introduced Full Page Display for Mac II, 640x864, 15", 75? dpi.
Price: $2000 including video card.  Rumored to be very sharp.

Currently has dual page display (19") for SE and +, next year sometime
will have one for the II.

 ************
 E-Machines, The Big Picture
 503-692-6656

Supposed to be very bright, and have 2 week delivery time.
    17" monitor
    1024x808, 82dpi
    list $2000, Apple National Accounts price $1600

 ************
 Network Specialities
 415-467-8411
    Next year will have 20" dual page display for Mac II
    1024x1024, 80dpi, ergonomic swival stand
    Currently is available for + and SE.

 ***********
 Sigma Designs Laserview
 415-770-0100

Comes with either a 19" or 15" monitor, and a dual mode video card

 mode        19" dpi        15" dip
 1664x1200    115        150
 832x600    58        75

The table shows that the 19" monitor is a real problem -- the dpi is
either far too high or far too low for readable text. Price: $2400 with
19", $1900 with 15"

Claim about a 1 month shipping backlog.


--

---- Henry Kautz
:uucp:    allegra!kautz
:arpa:    [e-mail]
:csnet: [e-mail]
:mail:  AT&T Bell Laboratories
    Room 3C-402A
    600 Mountain Ave.
    Murray Hill, N.J. 07974
:office phone: [phone]


------------------------------

From: [e-mail] (R.BRANDI)
Subject: Installer 2.5--where there's a will (+1 meg), there's a way
Date: 2 Dec 87 05:39:03 GMT
Organization: AT&T, Middletown NJ


In catching up with the past week or two of comp.sys.mac, I've noticed a
lot of grumbling about the brain-damaged way Installer works.  You'll
certainly get no argument from me on that count; the first time I tried
to update with Installer, I got caught in the same disk-swap dance.  But
I did find a way around it.  One catch--you need to have at least a meg
of memory so you can fit the system in a RAM disk.

The computer here is a Mac Plus, upgraded over time from a 128 that we
got used a while back.  The external drive is a single-sided 400K drive
(why do I have a Mac Plus and no Hard Drive, you ask?  Well, there's the
driveway that needs to be replaced, and the new stove that's needed, and
the deck we replaced this summer, and...you get the idea).  Anyways,
what I did was to take a 4.1/5.5 startup disk, and run a RAM disk
program (RAMStart 1.3, to be exact) which transfers all the system files
to the RAM disk.  The disk I set up was about 650K.  I probably could
have gotten away with about 100K less, but not much less than that
(ergo, the need for one meg...). Running Installer from one of the Apple
release disks (reconstructed from some on-line documentation I found on
one of the services-- Compu$erve, I think) transfers control to that
disk (the one Installer is on), and allows you to update the system on
the RAM disk.  Voila.  All you have to do is copy the contents of the
RAM disk onto your startup disk.  You have to do this by selecting all
the files, rather than dragging the whole RAM disk onto a disk-- when I
tried that, the System was renamed copy of System, and resolutely
refused to be renamed.  Anyways, by paring down to the absolute minimum
(system-necessary fonts only, 3 DAs, including Control Panel, Chooser
and Alarm Clock, no printer driver), I was able to fit a functional
MultiFinder startup system onto a 400K disk, which was the point of
doing this.  The system is now only (ONLY???) 203K.  Without using the
Installer, I wouldn't have been able to fit this all onto a 400K disk (I
wouldn't know what resources to delete with ResEdit).  Now if only I
could get rid of that Option-Command-Click About MultiFinder box--it's
cute the first time, but I really don't need it on a 400K disk....

I hope this helps.  I realize that it's only useful under a certain
limited set of circumstances, but it's good to know that there IS a way
to get around some things....

Ralph
--

    ====      | Disclaimer: Just `cuz I work on the Death Star,
 ==OOO=====   | that doesn't mean I speak for Darth Vader...
=OOOOOOO====  | Ralph Brandi, {ihnp4, all AT&T machines... }!lzfme!ralph
=OOOOOOO====  | Kopykat (k) 1987, R.A.Brandi    rutgers!mtune!/
 ==OOO=====   | All Rights Reserved, All Jams Preserved,
    ====      | All Nasty Comments Soundly Deserved...

"Time has little to do with infinity and jelly donuts..."


------------------------------

From: [e-mail] (Larry Hutchinson)
Subject: MPW C 2.0 Bug: PurgeSpace is foobar
Date: 2 Dec 87 16:45:43 GMT
Organization: Tektronix Inc., Beaverton, Or.

I have discovered yet another MPW C 2.0 bug.  It seems that the memory
manager glue proc 'PurgeSpace(total,contig)' uses the wrong trap word.
The trap that is called is _HSetState (with garbage as parameters)
rather than _PurgeSpace.  I have included at the end of this note an MPW
assembler proc to replace the faulty one.  Actually, I have included
two: my own code and an exact replica of the original code (which is
apparently machine generated).  I believe the code is correct, but you
need to check it out yourself.

But first, a few whining, sniveling comments:
    Why am I the only one to post MPW C bug reports to the net?
    Am I the only one that finds them?  -- Hardly likely (in spite of
    the popularity of LightSpeed C).
    Does everyone else already knows about them from GENIE or some
    other BBS or via MCI mail to developer support?
    Do other people just not bother?

    Come on, Jordan, surely a bug list exists for the MPW product line:
    why not save a few thousand hours of programmer time and publish
    it to the net?
--
Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 50-383, Beaverton, OR 97077
{ decvax,allegra }!tektronix!tekgvs!larryh


;
;    PurgeSpace.a
;        replaces the faulty version from MPW C 2.0
;

    INCLUDE     'Traps.a'
    CASE        ON        ; we're talking to c

;=====================================================================
;
; PROCEDURE PurgeSpace(VAR total,contig: LONGINT);
;=====================================================================
PurgeSpace    PROC    EXPORT

    _PurgeSpace
    move.l    4(sp),a1    ; addr of total
    move.l    d0,(a1)+    ; stow total
    move.l    a0,(a1)        ; and contig
    rts

    ENDP

    END


NOTE:  the above is my version of PurgeSpace.  The following is an
    exact replacement for the original code -- it just uses
    the correct trap.

    move.l    d2,-(sp)    ; save d2
    _PurgeSpace
    move.l    a0,d2        ; value of contig
    move.l    8(sp),a0    ; addr of total
    move.l    d0,(a0)
    move.l    12(sp),a0    ; addr of contig
    move.l    d2,(a0)
    move.l    (sp)+,d2    ; restore d2


------------------------------

From: [e-mail]
Subject: Source for Postscript
Date: 2 Dec 87 03:59:35 GMT
Organization: The Portal System (TM)

If anyone can offer me any source code on how to send Postscript to the
Laserwriter I would _greatly_ appreciate it.  Even if I can't get source
code, some clues or a general plan would be greatly appreciated.
--
Tim Dierks
[e-mail]
[e-mail]


------------------------------

From: [e-mail] (Bureau of Redundancy Bureau and Mattress Tag Police)
Subject: Followup to corrupted Excel file problem.
Date: 4 Dec 87 02:12:19 GMT
Organization: UTexas Computation Center, Austin, Texas


   Last week I posted a note about losing an Excel file - although the
file remained intact as far as my disk sector editor was concerned,
Excel could not read it without crashing.
    A few people sent me mail, saying that they had had that same
problem and requesting that I send the Excel file format if I find it
out. I haven't (nobody volunteered it, anyway), but I did a little
experiment, saving a file in all 4 Excel formats:
--
    File    Time        Preserve    Readable
File    Size    to Read        Formats &    via Sector
Type    (char)    In        Formulas    Editor
Excel    16830     5.91 sec    Yes        No
SYLK    16392    27.22        Yes        Yes
WKS    14370    23.39        Yes(mostly)    No
Text     3236    13.75        No        Yes

   By "readable" I mean you could crank up Fedit and read the numbers
straight off the screen. The SYLK format is documented in various
Microsoft manuals.
   The results imply that if you have a database that is very
important to you, you might want to keep it in SYLK or Text
format in case Excel decides to make it unreadable.

Wiley Sanders, Civil Engineering Dept, UT-Austin
secret NSA CIA anti Soviet Iran terrorist nuclear drug decoder ring
                                     - take THAT, NSA line-eater!


------------------------------

From: [e-mail] (Doug Moen)
Subject: rect.top vs: rect.topLeft in C
Date: 3 Dec 87 01:34:08 GMT
Organization: U. of Waterloo, Ontario

[e-mail] (Ted Johnson) writes:
>Can someone tell me what I'm doing wrong here?  Using Lightspeed C v.2.11,
>I tried to do the following:
>
>        tempPoint = aRect.topLeft;

[e-mail] (Richard Siegal@THINK Technologies) writes:
>    You're getting confused between C and Pascal. In C there's no easy
>way to get at the variants of a record. Therefore, there's a macro (declared in
>"QuickDraw.h") for "topLeft" and "botRight". Instead of "aRect.topLeft", say
>"topLeft(aRect)", and all will be well.
--
Although I haven't seen this exact trick used in any Mac C environment
so far, it *is* possible to define Rect so that you can use the
syntax described in Inside Macintosh for accessing its fields:

typedef struct {
    Point topLeft;
    Point botRight;
} Rect;

#define top    topLeft.v
#define left    topLeft.h
#define bottom    botRight.v
#define right    botRight.h

Note that LightSpeed C defines top,left,bottom and right as fields
and topLeft,botRight as macros, while the above implementation does
the reverse, *and* gives you a cleaner syntax.

Doug Moen
University of Waterloo Computer Graphics Lab
UUCP:     {ihnp4,watmath}!watcgl!kdmoen
INTERNET: [e-mail]


------------------------------

From: [e-mail] (Mike Klein)
Subject: Re: 4Dimension ???
Date: 3 Dec 87 21:07:12 GMT
Organization: Sun Microsystems, Mountain View, CA

In article <[e-mail]> [e-mail] (Jan Harrington) writes:
>The manual is relatively clear, or at
>least as clear as 4D manuals get.  Personally, I like the documentation, but
>I'm a programmer ...
>
>Because the program in so complex, the learning curve for
>productive use is very high.  There is a _lot_ of documentation, and you've
>got to wade through most of it to get a good picture of the package.  If
>you're not a programmer, you probably won't be happy with 4D (Guy Kawasaki
>disagrees, but that's another story).  In other words, to tap the power behind
>4D, you've got to write code.

I have a copy of 4th Dimension, and I personally think the manuals are
atrocious.  There are four of them: a "Tutorial," which is nothing of
the sort, a "User's Guide," a "Programmer's Guide," and a "Command
Reference." The only one of the four that has a suitable title is the
Command Reference. The other three look more like somebody gathered the
rest of the documentation on the floor into three binders at random.  I
am still trying to figure out how to do the simplest two-table join, and
I'm a programmer, too.  And then the vocabulary is different from what
you'll see in a course on relational data bases; an attempt, I assume,
to make the terms seem more "familiar" but to me it comes off as just
"different," which is always worse than sticking with the original.
Nowhere in the index do you find the word "join," for example.  You
figure out after a long time that instead you use the word "link."  And
there aren't any "tables" but "files" instead.  And on and on.

Now, it appears that 4th Dimension is powerful, but I have a lot of
other things to do with my time and the documentation is so poor that I
haven't actually gotten to the point where I can put together the
simplest data base and know why it does the things it does.  Until the
documentation is better, I don't consider this a product a non-data base
application developer can use.
--
Mike Klein        [e-mail]
Sun Microsystems, Inc.    {ucbvax,hplabs,ihnp4,seismo}!sun!klein
Mountain View, CA

------------------------------

From: [e-mail] (Howard A. Landman)
Subject: Re: Help wanted:  a LSC question
Date: 3 Dec 87 18:24:10 GMT
Organization: Intel Corp. ASIC Systems Organization, Chandler AZ

Assuming something like:

    typedef struct {int x, y;} point;

one way of describing a rectangle which would allow easy access is:

    typedef union
    {
        struct {int top, left, bottom, right;}    ints;
        struct {point topLeft, bottomRight;}    points;
    } rectangle;

which would allow references of the form:

    tempPoint = aRect.points.topLeft;
    tempInt = aRect.ints.top;

Note that this doesn't require the overhead of an extra variable to keep
track of variants.  Admittedly, Ted got confused, but that's no reason
to make incorrect accusations about C.

--
    Howard A. Landman
    {oliveb,hplabs}!intelca!mipos3!cpocd2!howard
    [e-mail]
    "I'm sorry, Dave, but I can't do that."


------------------------------

From: [e-mail] (Howard A. Landman)
Subject: Re: One Quick and Dumb ?
Date: 3 Dec 87 18:36:35 GMT
Organization: Intel Corp. ASIC Systems Organization, Chandler AZ

Try going into HyperCard, bringing up the message window, and executing

    hide menubar

I haven't tried this under MF, but it does hide the menubar under Finder
5.5. This is necessary, because some stacks USE the extra space (for
example, the rather odd periodic table stack that went through
comp.binaries.mac recently, and a rather infantile porn stack that
someone gave me).  I would be *VERY* surprised if this failed under MF -
Atkinson has specifically stated that he wanted HC to give programmers
control of the entire screen.  The HC paint tools work under where the
menubar used to be.

Oh yes, for the extremely naive, the way to get your menubar back is:

    show menubar

--
    Howard A. Landman
    {oliveb,hplabs}!intelca!mipos3!cpocd2!howard
    [e-mail]
    "I'm sorry, Dave, but I can't do that."


------------------------------

From: "William C. DenBesten" <[e-mail]>
Subject: Re: Mac II power switch
Date: Mon, 30 Nov 87 09:30:18 EST

MACWEEKBOS: ([e-mail])

> There must be some advantage to this "smart" switch, right? What is it??

On the lisa, I called it a "request to power down" switch.  The
advantage to it is that under normal operation, the user can not turn
off the computer with out the computer having a chance to update the
directory and other interesting stuff on the hard drive or any inserted
floppies.

Not having a Mac II ($$$ vs desire), I can't answer for sure, but:  You
should be able to recover by pressing the reset switch.

------------------------------

From: Atul Butte <[e-mail]>
Subject: Turbo Pascal ideas...
Date: Tue, 01 Dec 87 13:52:19 EST

I have Turbo Pascal (1.0a).  Is there anyone out there who knows how to
make INITS, FKEYS, MDEFS, WDEFS, CDEVS, etc... with Turbo Pascal?

Thank you in advance.
--
Atul Butte........................./---------\......./------------\
Brown University...................   OK    .......   CANCEL
[e-mail]............\---------/.......\------------/

------------------------------

End of Usenet Mac Digest
************************
-------